[レポート] 脅威検知とインシデント対応の自動化についてのワークショップに参加しました / Automating threat detection & incident response in your AWS environments #reinvent #SUP301-R1

はじめに

こんにちは、こたつで仕事がしたい Classmethod Canada の Funa です。今回はオペレーションチームでもよく取り扱っている脅威検知とインシデント対応についてのワークショップに参加したのでレポートします。

ワークショップ概要

In this workshop, learn how to detect threats and respond to them in automated manner using AWS services. Explore multiple security and logging services, and discover how to configure, aggregate, and correlate data between them. Detect threats using Amazon GuardDuty, AWS Trusted Advisor, AWS Config, and AW CloudTrail. Then, learn how to use AWS systems manager, AWS SNS, AWS Lambda, and AWS Step Functions to respond to the threats.

日本語化したものはこちらです。

このワークショップでは、AWS のサービスを使用して脅威を検出し、自動化された方法で対応する方法について学びます。複数のセキュリティサービスとログサービスを調査し、それらの間でデータを構成、集約、および関連付ける方法を発見します。Amazon GuardDuty、AWS Trusted Advisor、AWS Config、AW CloudTrail を使用して脅威を検出します。次に、AWS Systems Manager、AWS SNS、AWS Lambda、および AWS Step Functions を使用して脅威に対応する方法を学びます。

ワークショップ資料

• PDF: https://d1.awsstatic.com/events/Summits/reinvent2022/SUP301-R_Automating-threat-detection-and-incident-response-in-your-AWS-environments.pdf

セッション内容

脅威の検知・監視・対応の流れ

EC2 や S3 などのサービスの監視と脅威検知を行う Amazon GuardDuty、Amazon Macie、Amazon Inspector といったセキュリティサービスで生成された結果を集約して表示できるのが AWS Security Hub です。そこで対応を行うこともできますし、さらなる調査や分析を行うために Amazon Detective を使用することもできます。

Amazon GuardDuty とは

Amazon GuardDuty は、AWS アカウントとワークロード、データを継続的にモニタリングして脅威を検出するサービスです。

Amazon GuardDuty はどのように機能するか

Amazon GuardDuty は AWS CloudTrail イベントログ、VPC フローログ、DNS クエリログなどのデータソースから異常検出や機械学習、動作モデリングを使用して迅速に分析を行い、検出した結果を表示します。

Amazon Security Hub とは

Amazon Security Hub は、AWS 環境のセキュリティ状態を一元化して表示、セキュリティ警告を管理、セキュリティチェックを自動で行うことができるサービスです。

Amazon Security Hub はどのように機能するか

Amazon Security Hub は、Amazon GuardDuty や AWS Config、サードパーティのソリューションなどで生成されたセキュリティ結果を優先順位をつけて集約します。また、ベンチマークに基づいたセキュリティチェックを自動で行い、調査や対応、修正といったアクションを取れるようにします。

Amazon Security Hub のカスタムアクションを使って自動化する

AWS Security Hub のカスタムアクション機能を使ってセキュリティ結果を Amazon EventBridge に送信することができます。EventBridge のルールで Lambda や Kinesis Data Streams、SNS や System Manager の Run Command などをターゲットとして使用することで後続処理を行うことが可能です。

【弊社関連ブログ】

Trusted Advisor もあるよ

AWS Trusted Advisor のコアセキュリティチェックを確認して AWS のベストプラクティスに沿ったアクションを取ることもできます。

ワークショップ内容

ワークショップのドキュメントが公開されていないので、どのようなモジュールに取り組んだかをレポートします。

GuardDuty の基本的な使い方を学ぶ

モジュール 1 では基本中の基本的な GuardDuty の使い方を学びました。Amazon GuardDuty Workshop のモジュール 1〜6 までの内容と同じでしたのでご参照ください。

(ただし CloudFormation テンプレートがないので、ドキュメントの GuardDuty の開始方法 を見ながら進める方がやりやすいかもしれないです。)

EC2 インスタンスにキーペアが付与されていないことを検知する

3 つあった実践系モジュールの中で一番とっつきやすかったこちらのモジュールを試しました。

(re:Invent でのワークショップ中は CloudFormation で楽々だったのですが、家に帰ってからは以下のように、色々なリソースをポチポチと作っていく必要があって結構時間がかかりました！)

前提条件

・監視を行いたいリージョンで AWS Config を有効化してください。
・AWS Config の設定より、記録するリソースタイプを全てのリソースとして設定してください。

アーキテクチャ

1. EC2 インスタンスのコンプライアンスを評価するための Lambda 関数を作成する

Lambda に付与する IAM ロールの作成

1. IAM コンソールにアクセスし、ロールを選択して、「ロールの作成」をクリックします。
2. 信頼されたエンティティを選択する画面が表示されたら、ユースケースより「Lambda」を選択します。
3. IAM ポリシーAmazonEventBridgeFullAccess と AWSConfigRulesExecutionRole を付与します。

Lambda 関数の作成とデプロイ

1. Lambda コンソールにアクセスし、「関数の作成」を選択して、「一から作成」を選びます。
2. ランタイムは Python 3.7 を選択し、「デフォルトの実行ロールの変更」より上記で作成した IAM ロールを「既存のロール」から選びます。
3. 後ほど使用するので関数の ARN をどこかに保存しておきます。
4. コードソースで「lambda_function.py」を選択し、下記のコードをペーストし、Deploy ボタンをクリックします。

# Code Description: 
# - The lambda function code below is triggered when there is a configuration change to an EC2 resource. 
# - When triggered, the code will evaluate whether the EC2 instance (in the event object) has a keypair attached to it. 
# - The lambda will return the result of the evaluation to the target rule in AWS Config. 


import json
import boto3
import logging

# Create logger
logger = logging.getLogger()
logger.setLevel(logging.INFO)

# Handler function
def lambda_handler(event, context):
    
    # log event and contect
    logger.debug(event)

    # Get the invoking event
    invokingEvent = json.loads(event.get('invokingEvent'))
    configurationItem = invokingEvent.get('configurationItem')
    ruleParams = json.loads(event.get('ruleParameters'))
    
    # Log variables
    logger.debug(invokingEvent)
    logger.debug(configurationItem)
    logger.debug(ruleParams)
    
    
    # Evaluate compliance
    evaluation = evaluateCompliance(configurationItem)
    logger.info(evaluation)
    
    # Put evaluation in AWS Config (and associate with custom rule)
    config = boto3.client('config')
    response = config.put_evaluations(
        Evaluations = [{
            'ComplianceResourceType': configurationItem['resourceType'],
            'ComplianceResourceId': configurationItem['resourceId'],
            'ComplianceType': evaluation["compliance_type"],
            'Annotation': evaluation["annotation"],
            'OrderingTimestamp': configurationItem['configurationItemCaptureTime'] 
        }], ResultToken=event['resultToken'])
    logger.info(response)
    
    
    
def evaluateCompliance(configurationItem): 
    
    # Get configuration object
    configuration = configurationItem.get('configuration')
    keyName = configuration.get('keyName')
    logger.debug(configuration)
    logger.debug(keyName)

    if keyName: 
        result = {
            "compliance_type": "COMPLIANT", 
            "annotation": "Instance has been assigned a keypair."
        }
    else: 
        result = {
            "compliance_type": "NON_COMPLIANT", 
            "annotation": "Instance has not been assigned a keypair. "
        }        
        
    # Return result
    return result

(ワークショップの資料には Python 3.6 との記載がありましたが、Python 3.7 でも問題なく動作しました。)

2. AWS Config カスタム Lambda ルールの作成

1. Config コンソールを開き、ルールを選択し、「ルールを追加」を選択します。
2. カスタム Lambda ルールの作成を選びます。
3. AWS Lambda 関数 ARN に先ほど保存しておいた ARN をペーストします。
4. トリガータイプでは設定変更時を選択し、変更範囲はリソースを選択、リソースタイプで AWS EC2 Instance を選びます。

3. SNS トピックとサブスクリプションの作成

1. Amazon SNS コンソールを開き、タイプとして「スタンダード」を選択してトピックを作成します。
2. プロトコルで E メールを選択し、E メールアドレスを入力してサブスクリプションを作成します。
3. E メールアドレスに確認メールが届いたら、サブスクリプションを確認するリンクをクリックします。

4. Amazon EventBridge ルールの作成

1. Amazon EventBridge コンソールにアクセスし、イベントブリッジルールを選択してルールの作成をクリックします。
2. 名前を module-3、イベントパターンの AWS のサービスで「Config」を選択、イベントタイプは Config Rules Compliance Change を選びます。
3. 特定のメッセージタイプを選択し、ComplianceChangeNotification をクリックします。
4. 特定のルール名を選択し、先ほど作成した AWS Config カスタム Lambda ルール名を入力します。
5. ターゲットとして先ほど作成した SNS トピックを選択します。

今のままだと、キーペアが付与されていても通知が来てしまうので、イベントパターンの編集で newEvaluationResult 以下の部分を追加しました。

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "messageType": ["ComplianceChangeNotification"],
    "configRuleName": ["test-detection-lambda"],
    "newEvaluationResult": {
      "complianceType": ["NON_COMPLIANT"]
    }
  }
}

5. テストする

1.キーペアが付与されていない Amazon Linux 2 インスタンスを立ち上げます。

無事に立ち上がりました。

2.作成した Config ルールの対象範囲内のリソースでスコープを「非準拠」に変更して対象インスタンスが表示されることを確認します。

3.先ほど登録した E メールアドレスに「この EC2 インスタンスにはキーペアがアサインされていません！」といった旨の通知が届きました！

(番外) EC2 インスタンスにキーペアが付与されていることを検知したい場合

AWS Config のマネージドルールの ec2-no-amazon-key-pair を使いましょう。Lambda 関数やカスタムルールを作る必要がないので楽です。

感想

家に帰ってもう一回全部のモジュールをやり直すまで気づかなかったのですが、「インシデント対応の自動化」はモジュールに含まれてなかったです！笑
はじめにでも書きましたが脅威検知とインシデント対応は仕事でも触れるところですし、AWS 資格の勉強をする際にも学習するところなので馴染みがありましたが、AWS Config カスタム Lambda ルールは、全然触ったことなかったので学びがありました。